The present invention relates generally to the field of software identity determination, and more particularly to software identity determination in software containers.
A software container consists of an entire runtime environment: an application, plus all its dependencies, libraries and other binaries, and configuration files needed to execute it, bundled into one package. By “containerizing” the application platform and its dependencies, differences in operating system (OS) distributions and underlying infrastructure are abstracted away.
In general, software containers are considered to be “lightweight” when compared to virtual machines (VMs). Unlike a software container, a VM includes an entire OS as well as the application. For example, a physical server executing three VMs would have a hypervisor and three separate OSs executing on top of it. In contrast, in another example, a server executing three containerized applications executes a single OS kernel that each software container shares with the other software containers. Shared parts of the OS are read only and each software container has its own mount (i.e., a way to access the software container) for writing. That means the software containers are more lightweight in terms of the amount of code or types of software required and use fewer resources than VMs. For example, a software container may be only tens of megabytes in size whereas a VM, with its own entire OS, may be several gigabytes in size. Therefore, a single server can host far more software containers than VMs. Further, VMs may take several minutes to boot up their OSs in order to begin executing the applications they host. In contrast, containerized applications can be started almost instantly.
Because of their lightweight nature and agility, software containers have become increasingly popular. For example, DOCKER is an open-source project that automates the deployment of applications inside software containers by providing an additional layer of abstraction and automation of OS-level virtualization on LINUX. Cgroups (aka control groups) is a LINUX kernel feature often used to limit, monitor, control, and account the resource usage of certain processes (actually process groups). DOCKER uses resource isolation features of the LINUX kernel such as cgroups and kernel namespaces to allow independent LINUX software containers (LXCs) to execute within a single LINUX instance.
DOCKER is an example of the emerging trend for software container-based cloud systems. This is because software containers are rapid to deploy, execute, and migrate in a cloud system. The security of software container-based cloud systems hinges on the fact that software containers, as their name implies, are sealed. LXCs leverage cgroups to isolate the CPU, memory, file/block I/O and network resources. LXCs also use namespaces to isolate the applications from the operating system and separates the process trees, network access, user IDs, and file access. LXCs are considered a technique that falls between chroot and a VM in terms of security. Chroot is an operation that changes the apparent root directory for the current running process and their children. A program that is run in such a modified environment cannot access files and commands outside that environmental directory tree. Changing root is commonly done for performing system maintenance on systems where booting and/or logging in is no longer possible.